1. Field of Invention
The present invention relates generally to devices and methods for protecting computer software and in particular to devices and methods for protecting software by secure transmission and execution of encrypted software in a hardware key.
2. Description of Related Art
In the last decade, the use of computers in both the home and office have become widespread. The growing use of computers has resulted in extensive unauthorized use and copying of computer software, costing software developers substantial revenue. Although unauthorized copying of computer software is a violation of the law, the widespread availability of pirated software and enforcement difficulties have limited the effectiveness of this means of preventing software piracy.
Software developers and computer designers alike have sought technical solutions to attack the problem of software piracy. One solution uses an external device called a hardware key, or xe2x80x9cdongle,xe2x80x9d coupled to an input/output (I/O) port of the host computer. One such device is disclosed in U.S. Pat. No. 4,599,489, issued to Cargile on Jul. 8, 1986. The Cargile device executes a prescribed algorithm to produce a code which the computer receives and affords access to the software code if the code is correct. Another such device is disclosed in U.S. Pat. No. 4,446,519, issued to Thomas on May 1, 1984. This system also uses a hardware key coupled to the I/O port of a host computer. Software locks inserted into unprotected software programs cause the host computer to transmit a code to the hardware key. The hardware key processes the code to generate a response message. The software lock receives the response message, and compares the response to the expected response. If the received response is as expected, execution of the software is permitted to continue. If not, execution is terminated. A similar device is shown in U.S. Pat. No. 4,458,315, issued Jul. 3, 1984 to Uchenik.
Devices such as those disclosed in the Thomas and Uchenik references are not impervious to software piracy. Computer hackers can interrogate the dongle/host computer interface to determine query/response pairs, and could emulate the presence of a dongle with non-approved devices or software. In addition, computer hackers can obtain access to the protected software, find the software locks, and simply patch around them.
One solution to this problem is to perform selected software instructions in a secure hardware key, as disclosed in U.S. Pat. No. 4,634,807, issued Jan. 6, 1987 to Chorley et al. The Chorley device allows execution of portions of the protected software in a secure dongle coupled to a host computer I/O port. In the Chorley device, portions of the unprotected software, called software modules, are encrypted by a data encryption standard (DES) algorithm, producing a DES key and an encrypted module. The DES key is again encrypted, using a private/public encryption technique. The private key needed to decrypt the DES key is stored in the dongle. When the host computer requires execution of the software module, the encrypted software is transmitted to the secure dongle, and stored in its memory. The dongle processor decrypts the DES key using the private key, and uses the DES key to decrypt the software module. The software module is then stored in unprotected memory, where it can be operated on by a processor within the dongle. Access to the private and DES keys is controlled by a switch means which allows the dongle processor to access the memory in which the keys are stored only when the hardware key is initially activated. Upon activation, the private key is used to decrypt the DES key, and the DES key is used to decrypt the software module. Thereafter, the switching means prevents the dongle processor from accessing these keys.
While the Chorley device makes unauthorized access to the keys by the dongle processor difficult, it also prevents authorized access at any other time, and does not allow the memory in which the keys are stored to be used for other purposes. Also, the Chorley device is still not impervious to software piracy, because the unencrypted software module is eventually stored in the hardware key in an unprotected memory, where it can be accessed by the host computer. This may be prevented by enforcing encrypted and decrypted communications between the host computer and the dongle, such as disclosed in U.S. Pat. No. 4,596,898, issued on Jun. 24, 1986, to Permmaraju or U.S. Pat. No. 4,864,494, issued on Sep. 5, 1989, to Kobus, but this cannot be implemented with the Chorley device, because access to the keys is temporally limited.
Additional software protection devices are disclosed in U.S. Pat. No. 4,817,140, issued Mar. 28, 1989 to Chandra et al., and in U.S. Pat. No. 5,146,575, issued to Nolan et al. The Chandra and Nolan devices use a physically and logically secure co-processor to decrypt and execute software. Encryption and decryption keys and the algorithms using these keys are stored in the device in a secure non-volatile random access memory (RAM). Unlike Chorley, unauthorized access to plaintext software and the encryption/decryption keys is prevented by firmware-implemented functions rather than by a hardware switch. However, the Chandra and Nolan devices have practical limitations which limit their usefulness to prevent software piracy. First, the ultimate security of software protected by the Chandra and Nolan devices relies on the secrecy of a set of co-processor supervisor keys (CSKs) which must be pre-stored in all co-processors supplied by a given hardware vendor, and requires that the eventual software customer employ a use-once token cartridge to configure the co-processor to operate the protected software. The Chandra and Nolan devices also do not permit flexible access to other portions of the RAM which do not contain sensitive data. Because the Chandra device must be usable with a wide variety of software applications, it must employ an xe2x80x9copen architecture,xe2x80x9d and to prevent unauthorized access to sensitive information, is incapable of acquiring and transferring the right to execute the protected software. The Nolan device solves this problem by using a separate supervisor processor to implement a privilege structure and an open-architecture application processor to implement security functions. However, using two separate processors unnecessarily complicates the design and provides the potential software hacker with more opportunities to circumvent the software protection schemes employed in the device. The Nolan and Chandra devices are not immune from hacking by monitoring the co-processor/host interface, and using this data to emulate the hardware key.
Another problem with current software protection devices is that they are not backwards-compatible, and are not flexible enough to implement a wide variety of software protection algorithms within a single hardware key. For example a single host computer may store two separate software applications, the first protected with simple software locks, such as those described in the Thomas patent, and the second protected with encrypted computer/hardware key communications. Prior art software protection devices are incapable of supporting both of these software protection schemes, and two hardware keys would be required.
To overcome the limitations in the prior art described above, and to overcome other limitations that will become apparent upon reading and understanding the present specification, the present invention discloses a method and apparatus for protecting software executable on a computer.
The apparatus comprises a hardware key with a communicating means coupled to the computer for receiving command messages and providing response messages to the computer, a memory for storing data used in translating command messages into response messages to enable execution of software on the computer, and a processor coupled to the communicating means and the memory. The processor includes a means for interpreting command messages to generate processor command functions, a translator for generating response messages from the processor commands, and a memory manager to protect data from unauthorized access. The memory manager logically segments the memory into at least one protected segment and controls access to this protected segment. This is accomplished with an instruction mapper which selectively maps processor commands to memory address locations. The hardware key also employs a means for decrypting coded software and performing the decrypted instructions, and supports encrypted communications between the hardware key and the host computer. Additional capabilities are provided by programming interface module, command class dispatcher, and a license manager. The programming interface module allows secure programming of the hardware key without compromising its contents. The command class dispatcher provides for backwards compatibility of the present invention with other software protection devices. The license manager allows a software developer to use the hardware key to implement secure licensing schemes.
The present invention also discloses a method of securing executable software. The method comprises the steps of segmenting the software into a first and second software segment, transmitting the first segment to a first hardware key (the software developer""s hardware key), encrypting the first software segment in the first hardware key, and receiving the encrypted software segment from the hardware key. Because the keys used to encrypt the first software segment are securely stored in the software developer""s hardware key, they remain protected from unwanted disclosure. The encrypted segment can be stored in a magnetic medium along with the second (unencrypted) software segment or in a second hardware key that is provided to the software end-user.